1. Field of the Invention
This invention relates broadly to telecommunications. More particularly, this invention relates to a virtual concatenation (VCAT) and link capacity adjustment scheme (LCAS) which is applicable to both the synchronous digital hierarchy (SDH also known as SONET or the synchronous optical network) and the plesiochronous digital hierarchy (PDH).
2. State of the Art
The Synchronous Optical Network (SONET) or the Synchronous Digital Hierarchy (SDH), as it is known in Europe, is a common telecommunications transport scheme which is designed to accommodate both multiple DS-1 (T1) and E1 traffic as well as multiples (DS-3 and E-3) thereof. A DS-1 signal consists of up to twenty-four time division multiplexed DS-0 signals plus an overhead bit. Each DS-0 signal is a 64 kb/s signal and is the smallest allocation of bandwidth in the digital network, i.e. sufficient for a single telephone connection. An E1 signal consists of up to thirty-two time division multiplexed DS-0 signals with at least one of the DS-0s carrying overhead information. The higher order signals like DS3 and E3 are generally formed by bit interleaving lower order signals like DS1s and E1s. The E1 signal is an exception as it is byte interleaved.
Developed in the early 1980s, SONET has a base (STS-1) rate of 51.84 Mbit/sec in North America. The STS-1 signal can accommodate 28 DS-1 signals or 21 E1 signals or a combination of both. The basic STS-1 signal has a frame length of 125 microseconds (8,000 frames per second) and is organized as a frame of 810 octets (9 rows by 90 byte-wide columns). It will be appreciated that 8,000 frames*810 octets per frame*8 bits per octet=51.84 Mbit/sec. The frame includes the synchronous payload envelope (SPE) or virtual container (VC) as it is known in Europe, as well as transport overhead. Transport overhead is contained in the first three columns (27 bytes) and the SPE/VC occupies the remaining 87 columns. All of the bits in each payload octet come from a single source. Thus, unlike PDH, SDH is byte oriented rather than bit oriented.
In Europe, the base (STM-1) rate is 155.520 Mbit/sec, equivalent to the North American STS-3 rate (3*51.84=155.520). The STS-3 (STM-1) signals can accommodate 3 DS-3 signals or 63 E1 signals or 84 DS-1 signals, or a combination of them. The STS-12 (STM-4) signals are 622.080 Mbps and can accommodate 12 DS-3 signals, etc. The STS-48 signals are 2,488.320 Mbps and can accommodate 48 DS-3 signals, etc. The highest defined STS signal, the STS-768, is nearly 40 Gbps (gigabits per second). The abbreviation STS stands for Synchronous Transport Signal and the abbreviation STM stands for Synchronous Transport Module. STS-n signals are also referred to as Optical Carrier (OC-n) signals when transported optically rather than electrically.
To facilitate the transport of lower-rate digital signals, the SONET standard uses sub-STS payload mappings, referred to as Virtual Tributary (VT) structures. The ITU calls these structures Tributary Units or TUs. This mapping divides the SPE (VC) frame into seven equal-sized sub-frames or VT (TU) groups (TUGs) with twelve columns of nine rows (108 bytes) in each. Four virtual tributary sizes are defined as follows.
VT1.5 has a data transmission rate of 1.728 Mb/s and accommodates a DS1 signal with overhead. The VT1.5 tributary occupies three columns of nine rows, i.e. 27 bytes. Thus, each VT Group can accommodate four VT1.5 tributaries.
VT2 has a data transmission rate of 2.304 Mb/s and accommodates a CEPT-1 (E1) signal with overhead. The VT2 tributary occupies four columns of nine rows, i.e. 36 bytes. Thus, each VT Group can accommodate three VT2 tributaries.
VT3 has a data transmission rate of 3.456 Mb/s) and accommodates a DS1C (two DS1 signals combined) signal with overhead. The VT3 tributary occupies six columns of nine rows, i.e. 54 bytes. Thus, each VT Group can accommodate two VT3 tributaries.
VT6 has a data transmission rate of 6.912 Mb/s and accommodates a DS2 signal with overhead. The VT6 tributary occupies twelve columns of nine rows, i.e. 108 bytes. Thus, each VT Group can accommodate one VT6 tributary.
As those skilled in the art will appreciate, the original SONET/SDH scheme as well as the VT mapping schemes were designed to carry known and potentially foreseeable TDM (time division multiplexed) signals. In the early 1980s these TDM signals were essentially multiplexed telephone lines, each having the (now considered) relatively small bandwidth of 56-64 kbps. At that time, there was no real standard for data communication. There were many different schemes for local area networking and the wide area network which eventually became known as the Internet was based on a “56 kbps backbone”. Since then, Ethernet has become the standard for local area networking. Today Ethernet is available in four bandwidths: the original 10 Mbps system, 100 Mbps Fast Ethernet (IEEE 802.3u), 1,000 Mbps Gigabit Ethernet (IEEE 802.3z/802.3ab), and 10 Gigabit Ethernet (IEEE 802.3ae).
In recent years it has been recognized that SONET/SDH is the most practical way to link high speed Ethernet networks over a wide area. Unfortunately, the various Ethernet transmission rates (10 Mbps, 100 Mbps, 1,000 Mbps, and 10,000 Mbps) do not map well into the SONET/SDH frame. For example, the original 10 Mbps Ethernet signal is too large for a VT-6 tributary (6.912 Mbps) but too small for an entire STS-1 (51.84 Mbps) path. In other words, under the then existing SONET/SDH schemes, in order to transport a 10 Mbps Ethernet signal, an entire STS-1 path must be used, thereby wasting a significant amount of bandwidth. Similar results occur when attempting to map the faster Ethernet signals into STS signals.
In order to provide a scheme for efficiently mapping Ethernet signals as well as other signals such as Fiber Channel and ESCON into a SONET/SDH frame, the Virtual Concatenation (VCAT) Protocol was created and has been endorsed by the ITU as the G.707 standard (ITUT-T Rec. G.707/Y.1322 (December, 2003)) which is hereby incorporated by reference herein in its entirety. Similar to inverse multiplexing, Virtual Concatenation combines multiple links (members) into one Virtual Concatenation Group (VCG), enabling the carrier to optimize the SDH/SONET links for Ethernet traffic. For example, using virtual concatenation, five VT-2 (2 Mbps) links can be combined to carry a 10 Mbps Ethernet signal, resulting in full utilization of allotted bandwidth. Two STS-1 (51 Mbps) links can be combined to carry a 100 Mbps Ethernet signal, etc. Virtual Concatenation uses SONET/SDH overhead bytes (a nibble of all H4 bytes plus the second nibble of four of the sixteen “H4” bytes) to indicate two numbers: the multiframe indicator (MFI) and the sequence number (SQ).
Part of the emerging Virtual Concatenation Protocol includes methods for dynamically scaling the available bandwidth in a SONET/SDH signal. These methods are known as the Link Capacity Adjustment Scheme or LCAS. LCAS is a powerful network management tool because customer bandwidth requirements change over time. One simple example is a network user who, during business hours, needs only enough bandwidth to support electronic mail and worldwide web access. During non-working hours, however, the same network user may wish to conduct relatively large data transfers from one location to another to backup daily transactions. It would be desirable to alter the user's available bandwidth as needed. LCAS provides a means to do this without disturbing other traffic on the link. LCAS has been endorsed by the ITU as the G.7042 standard (ITU-T Rec. G.7042/Y.1305 (February 2004)) which is hereby incorporated by reference herein in its entirety.
While Virtual Concatenation is a simple labeling protocol, LCAS requires a two-way handshake (using seven of the sixteen H4 bytes for high order, STS-1, and seventeen of the thirty-two K4 bits for low order, VT1.5). Status messages are continually exchanged and actions are taken based on the content of the messages. For example, to provide high order (STS-1) virtual concatenation, each STS-1 signal carries one of six LCAS control commands which are described as follows:
“Fixed”—LCAS not supported on this STS-1 (“Fixed” is actually inferred rather than sent as a command. It is inferred when all of the LCAS fields other than MFI and SEQ are zero.);
“Add”—Expresses an intention to add this STS-1 to a VCG, thereby increasing the bandwidth of an existing VCG or creating a new VCG (Bandwidth is increased upon acknowledgement from the sink.);
“Norm”—This STS-1 is in use and is not the last member of a VCG;
“EOS”—This STS-1 is in use and is the last payload carrying STS-1 of this VCG, i.e. the payload carrying STS-1 with the highest SQ number;
“Idle”—This STS-1 is not in use in a VCG or is about to be removed from a VCG;
“Do not use”—This STS-1 is supposed to be part of a VCG, but does not transport payload due to a broken link reported by the destination. Members of a VCG which do not carry payload are termed “inactive” whereas members which carry payload are termed “active”.
The frame containing Virtual Concatenation LCAS information is called the VLI frame which contains the VLI byte and member status (MST) field which indicates one of the six LCAS control commands listed above.
Although SONET is said to be synchronous, it is actually plesiochronous. The clocks at different switches in the network actually differ in rate and also drift somewhat. Measures are provided to account for these clock differences which are seen as “justifications” in the overhead of the SONET signal. These justifications instruct the next switch in the path to add or remove “stuff bytes”. The stuff bytes are controlled by pointer movements to the SONET payload.
Due to the nature of the SONET network, it is possible for individual members of a VCG to traverse different network paths between their origin and destination. Because of this, members will arrive at their destination out of order and with different delays. This situation is generally referred to as “skewing”. In order to reassemble the members of a VCG in proper order without undue delay and without losing any members, the arriving members must be buffered and deskewed. Deskewing uses the multiframe indicator (MFI) as a time stamp to align all of the VCG members. Challenges to the deskewing process include: achieving minimal latency, accounting for justifications, adjusting for increases and decreases in member delay, dealing with the presence of inactive VCG members, and managing start-up and disruptions.
In its simplest form, deskewing involves placing members of a VCG in a buffer until the member with the most delay is received, then reading the members out of the buffer in the proper order. Typically, the members are written to RAM with an address based on their MFI numbers.
When link capacity is adjusted according to LCAS, the receiver acknowledges the adjustment by toggling the RS-Ack (resequence acknowledgement) bit in the LCAS control packet. Resequencing is detected through VLI control packet processing. According to the state of the art, the VLI (H4) octet is processed twice, once for deskewing and then again for resequence acknowledgment after deskewing.
From the foregoing, those skilled in the art will appreciate that VCAT and LCAS are powerful tools for linking together LANs from all over the industrialized world. However, as initially implemented VCAT and LCAS only operate between SONET (SDH) nodes. In order for a business to couple its LAN to others around the world, the LAN must first be coupled to a SONET (SDH) node. If the business is close enough to a SONET (SDH) node, the LAN can be coupled to it via a standard Ethernet LAN connection. Alternatively, the business can install its own SONET (SDH) node and couple it by fiber to the public SONET (SDH) network. However the former is frequently not an option and the latter can become expensive if fiber needs to be laid from the business to the public network.
Concurrently with the development of SONET(SDH), VCAT, and LCAS, standards were being set for the transmission of packet data such as Ethernet over existing DS1, E1, and DS3 links which were originally installed to carry telephone calls and low bandwidth data transmissions. In 1998 the ITU-T updated Recommendation G.704 (October 1998) (hereby incorporated by reference herein in its entirety) which defines synchronous frame structures at bit rates equivalent to existing T1 (DS1) 1.544 Mbps, E1 2.048 Mbs, T2 (DS2) 6.312 Mbps, E3 8.448 Mbps, and T3 (DS3) 44.736 Mbps bit rates. These frame structure definitions created what is now referred to as the plesiochronous digital hierarchy (PDH). With these frame structures defined, the ITU-T adopted Recommendation G.832 (October 1998) (hereby incorporated by reference herein in its entirety) which defined framing and multiplexing structures for the transport of “SDH elements on PDH networks.”
Those skilled in the art will appreciate that T1, and to a lesser extent T3, links between large and mid-size business and the public network became ubiquitous as early as the 1980's. During the 1980's data communication techniques were established whereby data communications could take place over public and private networks using T1 and T3 backbones. With the definition of the PDH, it became easier for organizations having T1 or T3 connections to link their LAN to the public SONET (SDH) network.
Recently, the ITU-T adopted Recommendation G.7043/Y.1343 (July 2004) and Amendment 1 (January 2005) (hereby incorporated by reference herein in their entirety) which describes VCAT for PDH signals. While VCAT for PDH is similar to VCAT for SONET/SDH, there are significant differences due to the differences between PDH and SDH. As mentioned above PDH is generally bit interleaved whereas SDH is byte interleaved. This makes PDH VCAT members incompatible with SDH VCAT members unless they are byte aligned first. In addition, SDH VCAT is defined at the SDH path level but the members are multiplexed to a line at a line rate. Thus, the VLI frame is inherently multiplexed at the SDH line rate. PDH VCAT is defined at the PDH line level. Thus, the PDH VLI frame is not tied to the SDH line rate. LCAS is implemented in the same way for PDH and SDH.
Implementing VCAT when connecting a LAN to a SONET network via PDH links requires equipment at the point where Ethernet is mapped onto PDH. Once the Ethernet over PDH (EoPDH) signal is received at the SONET node, it is treated just like any PDH signal and the fact that it contains Ethernet packets is irrelevant to the SONET network. When the EoPDH over SONET (EoPDHoSDH) signal reaches its destination SONET node, the PDH streams are extracted and sent via PDH links to equipment which is configured to extract the Ethernet packets and place them on an Ethernet LAN. This system works if both the origin and destination are coupled to the SONET network by PDH links. If however, one end user is coupled by PDH and the other end user is coupled by SDH, they cannot properly communicate. This is because of the differences described above in the manner in which VCAT is implemented for SDH and PDH.
The state of the art solution to this problem is to provide the SDH connected user with a PDH connection as well. Two separate VCAT/LCAS units are provided, one for the SDH link and one for the PDH link. This solution essentially doubles the amount of VCAT/LCAS processing equipment which makes it expensive. Moreover, since it is desirable to provide VCAT/LCAS solutions on a single chip, the state of the art solution either fails to accomplish that result or requires design of a much larger chip to implement VCAT/LCAS.